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MOBILE COMMERCE MEClEBPT SYSTEM 



The invention relates to the field of mobile telecommunications services, particularly a 
system, and a method for use in said system, for providing to a user of mobile 
5 telecommunications a receipt or proof confirming a purchase, payment and/or other e- 
commerce transaction made by the user. 

FIELD OF THE INVENTION. 

10 Mobile e-commerce can be defined as commerce for mobile users made available via 
mobile devices such as mobile phones, PDAs (Personal Data Assistant), palmtop, etc. 
The mobile user has the possibility to do shopping, ticketing, banking, betting, trading 
via his mobile phones. 

is THE PROBLEM AREA. 

In web commerce goods, except electronic ones or services, are usually delivered later 
on. With mobile e-commerce, the user should be able to access the same commerce 
services with postponed delivery as the web but in addition, he must be able to access 
20 commerce services with short time delivery. For example, a user when on the move and 
thirsty, wants to get the soft drink from the automat right after having paid via his 
mobile phone. Another mobile user when visiting a city and wanting to see a movie 
expects to be able to collect the ticket at least before the beginning of the show. 

25 In such situations, the entity performing the actual delivery, that could be a human 
being or a machine, needs to receive the authorisation for delivery quite rapidly. In 
addition, as in the case of the cinema ticket, the user needs to receive some sort of 
electronic receipt that he shows to the delivery entity to get the cinema ticket. Such an 
electronic receipt must fulfil the requirements: 

30 o It needs to be recognisable by the delivery entity 

o It can be used as a proof to show that the holder of the receipt has made the purchase 

and that the ordered goods and/or services can be delivered to the holder 
o It cannot be falsified 
o It cannot be duplicated or used twice 



35 



Accordingly, there is a need for a receipt system in mobile e-commerce. 
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KNOWN SOLUTIONS AND PROBLEMS WITH THESE. 

International patent publication number W099/66436 discloses an electronic verified 
payment system (VPS) comprising a distributed verified trusted third-party system and 

5 method enabling electronic/digital transactions through real-time verification and 
authentication. The VPS includes hubs storing client data and connecting clients, such 
as users of mobile phones, palm-tops and digital television, to vendors to mediate 
secure electronic transactions. International patent publication number W098/4321 1 
discloses a digital payment transactions system wherein a broker generates and stores a 

10 secret number to be the start number for a chain of hash values by successive operations 
of a hash function. The values are associated with coins in a coin stick provided by the 
user, enabling secure payments in subsequent electronic transactions involving 
payments. Other systems and/or methods for electronic payments, of which some utilise 
a third party or a mediator, are disclosed in EP-A1 -0865010, WO99/46720, 

15 US5999596, WO99/49404 and EP-A1 -0971 302. None of these* however, provide the 
user with a specific and reliable proof of the transaction made. 

Other known systems for purchasing cinema tickets by telecommunication means, such 
as the one offered by Telenor Mobile in Norway, have only a very primitive scheme for 

20 receipt. After that the user confirms the acquisition of the tickets by entering through a 
telephone his PIN (Personal Identification Number) code, the user will receive a code, 
e.g. a 4 or 6 digit number. To collect his cinema tickets, the user presents the code at the 
ticket window. The ticket window attendant then compares the code presented by the 
user with one received from the system. If they match, then the attendant is authorised 

25 to hand out the purchased tickets to the user. 

An example of an existing mobile e-commerce is depicted in figure 1. The user uses a 
mobile phone equipped with a browser, e.g. a WAP (Wireless Application Protocol) 
browser or a SIM (Subscriber Identification Module) Application toolkit browser, etc. 

30 allowing the user to browse on the World Wide Web via a gateway. The gateway can be 
a WAP gateway, an SMS (Short Message Service) gateway or any specific server 
capable of communicating with the browser on the mobile phone. The user visits a 
merchants or vendor's web site. He contemplates the offers and selects the items that he 
wants. He pays for them through a payment scheme. The payment scheme may be for 

35 example based on a prepaid account, a credit or debit card or a bank account. He 
receives from the merchant a code that he can present when collecting the purchased 
items. 
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Such a system is simple but relies totally on the reliability of the merchant's system. It is 
only satisfactory if the delivery entity gets both the correct code and the correct 
information about the ordered tickets, e.g. theatre, movie, seats, etc. Otherwise* the user 
5 will not receive the tickets that he has paid for. In case of failure, the user has only a 
code that is insufficient to prove that he has bought the tickets. Of course he will not be 
charged for the tickets in such a situation but this is not what he wants. It is quite 
frustrating not be able to watch the movie that one likes and has paid for. 

10 As stated above, the current solution with a simple code is not sufficient since the user 
has to rely totally on the reliability of a vendor or merchant, and her/his system. 
Although the merchant may be honest and does not have the intention to play tricks on 
the user, if a fault occurs in his system the user will not get delivered the goods or 
services that actually has been bought, and usually paid for. Also* a mismatch between 

is the ordered goods or services and what is actually delivered to the user can occur. 

BRIEF DISCLOSURE OF THE INVENTION. 

Ideally, a contract stating all the details of the deal, i.e. the goods and/or services 
20 ordered, prices and quantity, etc. should be signed digitally by the merchant and then 
sent to the user mobile phone for local storing in the phone. At the delivery counter, the 
user can connect his phone via for example a cable, a socket or wireless using Bluetooth 
or IEEE 802.1 1 to the delivery system and hand over the signed contract. The delivery 
entity verifies the signed contract and if valid delivers the goods and/or services to the 
25 user. 

To realise such an ideal solution, certain adaptations of the existing technology should 
be made to meet the demands of the ideal solution. Aspects to consider in this regard 
are: 

30 o A detailed digital contract is rather large and the mobile phone may not have 

sufficient storage capacity for storing multiple contracts, which is necessary when 
the user buys several items, 
o If the mobile phone is broken or stolen the user will loose all his contracts and hence 
may also loose all his purchase. Of course, the user can always claim to the 
35 merchant but it 's up to the merchant to decide. 

o The delivery entity must have sufficient capability to verify rapidly the digital 
contract and this could be unacceptable from the economical point of view. 
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• In some situations, the merchant having the deal with the user may not be the same 
as the delivery entity and a contract showing all the details about the user, address, 
prices, etc. may be inappropriate since the user's privacy can be a concern. 

The present invention provides an arrangement for providing mobile commerce receipts 
to e-commerce users with the features of the accompanying claim 1 and dependant 
claims 2 -3. 

Also, the present invention provides a method for providing mobile commerce receipts 
to e-commerce users with the features of the accompanying claim 4 and dependant 
claims 5-7. 

BRIEF DESCRIPTION OF THE DRAWINGS. 

Fig. 1 shows a schematic representation of a prior art e-commerce system and the 
various procedures involved in its use. 

Fig. 2 shows the overall architecture of a mobile e-commerce receipt system according 
to the present invention. 

Fig. 3 is an illustration of information flow and the associated steps in a method 
according to the present invention. 

DETAILED DESCRIPTION OF THE INVENTION 

In the following, the invention will be explained by way of embodiment examples and 
with, reference, to* the accompanyingdrawings.- 

Referring to fig. 2, the overall architecture of a system according to the invention is first 
explained. 

In order to avoid the problems described in the previous paragraph, and to at the same 
time to enable short time goods and/or services delivery that is usually required in 
mobile e-commerce this invention proposes a system as shown in fig. 2. The system 
comprises of the following entities: 

• Mobile phone with a browser 

• Gateway 



BNSDOCID: <WO 0186538A1_I_> 



WO 01/86538 




• 



PCT/SE0iy00975 ' 



5 



o Delivery entity terminal 

o Trusted Third Party receipt server 

o Merchant (Vendor) Server 

5 A Trusted Third Party (TTP) receipt server is a new entity introduced between the user 
and the merchant. It acts like a neutral intermediary that gives equal protection to both 
parties, i.e. the user and merchant. In addition, it will enable the short time delivery 
feature that is required in mobile e-commerce. Since the mobile phone does not have 
enough capacity for storing the contract, the TTP is storing the contract on behalf of the 

10 mobile phone and the mobile user. Based on the contract, the TTP will issue and sign a 
simpler and smaller receipt that could be stored in the mobile phone. This digital receipt 
is then returned to the merchant's server that sends it to the mobile phone. The digital 
receipt is stored in the mobile phone and will be used at the delivery of goods and/or 
services. 

15 

Now, with reference to fig. 3, the workings of the system is explained. 
As shown in fig.3, the system works as follows: 

1 . The mobile user browses on his mobile phone and visits a merchant's web site. He 
selects the items that he wants and makes an order. 
20 2. The payment procedure is carried out. Note that different payment schemes may be 
used according to the merchant's system and the user's subscription, e.g. prepaid 
account, credit card, debit card, bank account, etc. 
3. The Merchant' s server generates and digitally signs the contract using the merchant 
private key. The contract may contain the following attributes: 
25 o customer name 



30 



35 



o customer address 

o customer e-mail 

o MISDN number of the mobile phone 

o credit card number and expiration date(in case of payment by credit card) 

o merchant name and ID number 

o merchant address 

o merchant e-mail 

o date and time of contract 

o contract id 

o delivery place (if necessary specify the delivery entities) 

o earliest delivery date and time (if necessary) 

o latest delivery date and time (if necessary) 
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• list of items with quantity for each item, unit price, part no 

• total amount paid 

The contract is then sent to the TI P. 

4. The TTP validates the contract to make sure that it is valid and does originate from 



functions. If it is the case, the TTP will store it. Based on the digital contract the 
TTP will then generate and sign a receipt using its private key. This digital receipt 
may contain the following: 

• contract id 
10 • TTP id 

• TTP address 

The TTP will then send it to the merchant's server. 
5. The merchant's server sends the digital receipt to the user's mobile phone that stored 
it. 

15 6. At the delivery counter, the user connects his mobile phone to the delivery entity's 
terminal. This can be done via a wire, a direct contact, infrared or a wireless link 
such as Bluetooth, IEEE 802.1 1, etc. The mobile phone hands over the digital 
receipt to the delivery entity's terminal. 
7. At this stage there are two alternatives depending on the capability of the delivery 

20 entity's terminal : 

a. It validates the digital receipt. If valid, it will fetch the corresponding contract 
either from the merchant's server or from a repository in order to find the list of 
purchased items. Go over to step 9. 

b. It is not capable to perform the validation of the digital receipt by itself. It will 
25 then get in touch with the TTP by using the address specified in the digital 

receipt and send over the digital receipt for validation* 

8* 

contract by using the contract id specified in the receipt. It will extract the list of 
purchased items and send it together with an OK back to the delivery entity 
30 terminal. 

9. The purchased items are delivered to the user. The delivery entity asks the user to 
acknowledge that he has received the goods and/or services. This can be done via 
verbal communication between the person in charge of the delivery or via the 
delivery entity terminal that sends an acknowledge request to the mobile phone via 

35 the link between the two devices. 

10. The user acknowledges via his mobile phone that the goods and/or services have 
been delivered to him. The mobile phone sends an acknowledgement to the TTP. 



5 



the corresponding merchant. The validation is done using public key cryptographic 
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The acknowledgement can simply be the digital receipt digitally signed by the 

mobile phone using the user's private key. 
1 1 . The TTP validates the acknowledgement to make sure that it does originate from the 

right user and is not modified. If valid, the TTP will save it with the corresponding 
5 contract. The TTP will then send an OK to the Delivery Entity terminal. 
The trade is hence concluded. 

The Trusted Third Party receipt server assumes the following responsibilities: 
o Ensure that the interests of both parties are equally protected 
ro o Store the contract for the user such that can be used in case of dispute, 
o Issue a simpler receipt that can be used in the delivery phase 
o Certify that a trade is concluded successfully with a delivery of goods and/or 
services 



is The Trusted Third Party receipt server has the following functions and capabilities: 
o receive and validate contracts signed by merchants 
o store and retrieve contracts 

o issue and digitally sign receipt based on the received contracts 
o validate digital receipts 
20 o validate acknowledgements 

o store and retrieve acknowledgements 

o have access to necessary cryptographic function in order to perform signing, 
verification and validation of receipts and acknowledgement. 

25 The Delivery Entity's terminal is located at every delivery counter. It assume the 
following responsibilities: 

o accept the digital contract and send it to the TTP for validation 
o receive delivery information from the TTP 
o ask for delivery acknowledgement 

30 

The Delivery Entity's terminal has the following capabilities: 

o communication with the mobile phones 

o communications with the TTP and the merchant's server 



35 Certain features of the communications can identified as: 
o between TTP and Merchant's server 
o between TTP and Delivery Entity's Terminal 
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• between Delivery Entity's Terminal and Merchant's server 

• can go through secure channels on the Internet, i.e. encrypted or through dedicated 
networks. 

5 The communication between the mobile phone and the TTP goes through the mobile 
network, the gateway and the Internet. 

The communication between the mobile phone and the Delivery Entity's terminal can be 
via a cable, a socket, or wireless via infrared, Bluetooth, IEEE 802.1 1. 

10 

ADVANTAGES 



This invention has much merit: 

• It enables short time delivery that is required in mobile e-commerce, while not 
15 requiring much capability either on the mobile phone or the delivery entity's 

terminal 

• It provides adequate protection to the user. In case of failure in the merchant's 
system, the contract digitally signed by the merchant, which is stored by the TTP 
can be retrieved and used as proof. In the case where the mobile phone is broken or 

20 stolen the user does not loose the goods and/or services that he has paid for. The 
privacy of the user is achieved in the sense that information such as identity, 
personalia, credit card number, bank account, etc. is not revealed at the delivery 
entity. 

• It provides adequate protection to the merchant, it ensures that purchased items 

25 cannot be delivered twice since delivery acknowledgements are stored by the TTP. 

• It is realisable without requiring much effort and resource. 
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1. 

A method of providing a mobile telecommunication terminal (MTT) of a customer 
5 entity (CE) with a reliable simpler electronic proof of a reservation, purchase and/or 
payment being made by the CE by means of an e-commerce arrangement, including the 
steps of: 

- making, by the CE, a goods or service specifying electronic reservation, purchase 
and/or payment with a merchant entity (ME), 

io - generating, in the ME, a transaction record (TR) on basis of the reservation, 
purchase and/or payment, and, on basis of the TR, an electronic contract (EC) 
including an identity (ID) of the ME, 
characterised in: 

- transferring a copy of the EC from the ME to a trusted third party entity (TTPE), 

1 5 - generating, in the TTPE, a verified EC (VEC) on basis of a verification of the ID of 
the ME included in the EC, and a simpler electronic receipt (SER) on basis of the 
VEC, 

• transferring a copy of the SER from the TTPE to the ME, and 

- transferring a copy of the SER from the ME to the MTT. 

20 

2. 

A method of using a simpler electronic receipt (SER) generated by a trusted third party 
(TTPE) and provided -to a mobile telecommunication terminal (MTT) of a customer 
entity (CE) who has made an electronic reservation, purchase and/or payment by means 
25 of an e-commerce arrangement, for claiming a reserved, purchased and/or paid goods or 
service, including the steps of: 

- presenting the SER to a delivery entity (DE) by transferring a copy of the SER from 
the MTT to the DE, 

characterised in: 
30 - transferring a copy of the SER from the DE to the TTPE, 

- generating, in the TTPE, a validated SER (VSER) on basis of a transaction record 
(TR) of a corresponding reservation, purchase and/or payment, and a validated and 
verified specification of a goods or service on basis of the VSER and the TR, and 
transferring the validated and verified specification of a goods or service from the 

35 TTPE to the DE. 
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3. 



A method of providing a simpler electronic receipt to a mobile telecommunication 
terminal (MTT) of a customer entity (CE) at making a goods and/or service reservation, 
purchase and/or payment by means of an e-commerce arrangement, and of using the 
s SER for claiming the reserved, purchased and/or paid goods and/or service, the method 
including the steps of: 

al) at the time of making the goods and/or service reservation, purchase and/or 



generating, in the ME, a transaction record (TR) on basis of the reservation, 

purchase and/or payment, and, on basis of the TR, an electronic receipt contract 

(EC) including an identity (ID) of the ME; 
bl) at the time of claiming the goods and/or service reserved* purchased and/or paid: 
15 - presenting the SER to a delivery entity (DE) by transferring a copy of the SER from 

the MTT to the DE, 
characterisedin: 

a2) at the time of making the goods and/or service reservation, purchase and/or 
payment: 

20 - transferring a copy of the EC from the ME to a trusted third party entity (TTPE), 

- generating, in the TTPE, a verified EC (VEC) on basis of a verification of the ID of 
the ME included in the EC, and a simpler electronic receipt (SER) on basis of the 
VEC, 

- transferring a copy of the SER from the TTPE to the ME, 
25 - transferring a copy of the SER from the ME to the MTT; 

b2) at the time of claiming the goods and/or service reserved, purchased and/or paid: 

- transferring, a copy of the SER from the DE to. theXTPE^ 

- generating, in the TTPE, a validated SER (VSER) on basis of a transaction record 
(TR) of a corresponding reservation, purchase and/or payment, and a validated and 

30 verified specification of a goods or service on basis of the VSER and the TR, and 

- transferring the validated and verified specification of a goods or service from the 



35 The method of any one of the previous claims, characterised in that 
the TR includes: a CE identifier, a MTT identifier, a ME identifier, an identifier of a 
corresponding EC, a TR identifier, and optionally a goods and/or services specification. 
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payment: 

making, by the CE, a goods or service specifying electronic reservation, purchase 
and/or payment with a merchant entity (ME), 



TTPE to the DE. 



4. 
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5. 

The method of claim 4, characterised in that the TR further 
includes at least one of the following: customer address, customer e-mail, MISDN 
s number of the mobile phone, credit card number and expiration date, merchant name 
and ID number, merchant address, merchant e-mail, date and time of contract, contract 
id, delivery place, earliest delivery date and time, latest delivery date and time, list of 
items with quantity for each item, unit price, part no and/or total amount paid. 

10 6. 

Themethodofanyoneofclaims3-5, characterised in the further 
steps of: 

- converting, in the TTPE, at least a portion of the SER by encryption before 
executing the step of transferring a copy of the SER from the ME to the MTT; and 

is - converting, in the TTPE, an encrypted portion of the SER by decryption after 
executing the step of transferring a copy of the SER from the DE to the TTPE. 

7. 

The method of any one of claims 2 - 6, characterised in the further 
20 steps for providing to the DE a confirmation of a completed delivery of a claimed goods 
or service: 

transferring a delivery acknowledge request (DAQ) from the DE to the MTT, 

- transferring a delivery acknowledge confirm (DAF) from the MTT to TTPE, 
validating, in the MTTE, the DAF, and 

25 - transferring an indicator of a valid DAF to the DE. 

8. 

The method of any one of the previous claims, characterised in that 
the SER comprises a EC identifier and a TTPE identifier. 

30 

9. 

The method of any one of claims 2-8, characterised in that 
transferring the SER to the DE is accomplished by means of wire, a direct contact, 
infrared or a wireless link. 



35 
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* 10. 

The method of claim 9, characterised in that the wireless link is a 
Bluetooth or IEEE 802.1 1 enabeled link. 
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